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Ab many or gani z at i onB transit through t4oian-s phases of 
ADP evolution*, the process of designing systems to satisfy 
their data neceds has become eMtremely compleM» App }. i cat i on- 
oriented design techniques have given way to dat a-or i ent ed 
concepts such as In-formation Engineering* One of the 
primary tools of Information Engineering is the group of 
manage^ment functions known as Data Admi ni str at i on . Naval 
Supply Systems Command (NAVSUP) has esstablished a data 
admi ni strat i on branch in an attempt to integrate three 
logistic information systems s SUADPS REAL-TINE.;, LJADPS-S5P and 
U I CP * 
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Through the years, the design, i mpl. emen t at i on , and 
maintenance of computer information systems has become one 
of the most important elements of an effective organi jzati on , 
An army^^is commonly referred to as “marching on its 
stomach". An orqani Tzat i on marches not only on the content 
of its information, but also on how it accesses that 
information up and down its or gani c at i onal structure. 

Many organizations are evolving towards Richard Nolarr s 
concept of “mature" data processing users CRef. 13. 

Computers are no longer used just to assist the operational 
managers in the day to day tr ansae t i onal processing as they 
were five to seven years ago- Managers at all levels of the 
organization need information to »nake countless decisions. 
Today's computer technology provides the capability to 
retrieve needed information from throughout the 
organ! z at i on . However , the weak 1 i nk i s the compat i bi 1 i ty 
of data and data structures to allow access to the 
information of the or gam z at i on . 

Much attention has been given to the development and 
1 >nprovemen t s in computer hardware. These improvements have 
been easy to observe. Early computers that contained small 
a ! n o u n t s of m e oi o r / w e r e p h y s i c a 1 1 v h u. q e a r'« d r e q u. i r e d 1 a r q e 
1 n V e s t f n e n t s of c a p i t a 1 11 a a g e m e n t c: <::• n c e i“ n w a s i t. r< k e e p i r' g 



the computer busy by processing millions of transactions 
that were relatively easy to program- Today, processors 
which possess almost a million bytes of computer memory are 
comrnonpl ace on workers" desks throughout the organi z at i on . 
Computers have become smaller, cheaper, faster^ more 
reliable, and easier to maintain than earlier models. r-4ow 
management concern is with coordinating ail the computer 
systems in an organization in order to support and control 
an effective overall information system. 

The Naval Supply Systems Command (NAVSUP) is similar to 
any large organization with computer information systems. 

In the? mid 1960" s, NAvSUP developed three major financial 
and inventory control systems to provide support for its tri 
level or qani z at i on - They are the Shipboard Uniform Automated 
Data Processing System (SUADPS3), the Uniform Automated Data 
Proce?ssing System for Stock F-'oints (UADPS-SP) , and the 
Uniform Inventory Contr'ol Point sytem (UICP) - These systems 
were «d e s i g n e d u sing second genera t. i o n h a i - (.i w a. r e a n d c- o f t ware 
techniques with major emphasis on i vi dual file 
process! ng . 

Today, all three of these major sysstems are being 
redesigned to utilize the state of the art hardware 
i: e c h n o 1 o g y . NAVSUP ! "i a ?=• t h e u f! i q u e o [::« p o r t u. n i *: y t o d e s i g n 
1: hi e s s y s t e m s t o p r o i ci e i n t e q r a t .i. o r“‘ t !"• r o u g h o u. t t h e 
o r Q a fi i z a t i a n a n d t o t a !•••: e a n i ! r? p o r t a n t s t e p t o w a r d s r t?? a 1 i z i n g 
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a true corporate i nf orjT^at i on system allowing top management 
access to the in-formation that they need. 

This thesis will discuss the problems o-f coordinating 
the design of the three systems experienced by NAVSUP with 
an emphasis on the role of data admi ni str at i on in the 
overall concept of information systems. Much attention will 
be given to the concepts of software design including the 
basics of Information Engineering which is being used by the 
Fleet Material Support Office <FMSO) ^ the central design 
activity for UADPS-3P and UICP. After the discussion of the 
three replacement systems, the need for a strong data 
admi ni st rat i on activity at NAVSUP Headquarters to allow for 
vertical integration will be emphasiired. 



II, BACKGROUND 



A- NAVSUP ORGANIZATION 

NAVSUP supports logistic operations through a tri -level 
organ! zat i onal structure as shown in Figure in The bottom 
layer i^ the ship or squadron supply department which 
maintains an inventory of up to 100,000 line items for 
issue. If a needed part is not available, a referral is 
sent to the next level, the nearest stock point (Naval 
Supply Center or Depots. A stock point carries an inventory 
of between 90, 000 and 1 , 500, 000 i terns and sat i sf i es 
approM i mat el y 75% of the referral requests it receives. The 
unfilled referrals are sent to either the Aviation Supply 
Office (ASO) or the Ship Parts Control Center (SPCC) , the 
third level in the logistic chain. ASO and SPCC do not 
stock any parts for issue. They function as inventory 
control points (ICPs) and moni tor the worldwide inventory of 
supply parts, the status of depot level repai rabies, and the 
contracts for new procurements. The two ICP"s handle over 
2,000,000 demands every month. The ICP will direct the 
issue of a needed part from any supply source throughout the 
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Figure 1 — Logistic Support Organization 

Each level in the supply chain utilizes a different 
sophisticated automated inventory control sys^tem. These 
computer system»s were? et-fective in the past in assisting the 
NAVSIJP activities in per-forminq thieir missions- However, 

-for the last ten years, the pace ot operations and the -sheer 
size of the computing load have created a desperate need for 
modern information systems at all levels- Add i t i onal 1 y , 
NAVSIJP headquarters now needs access to information at all 
three levels jnuch fastt-^r than what is currently 
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The Navy-s in-formation needs have changed dramatically 
since the earlier systems were developed. They were 
designed as report generators executing in batch mode to 
provide page upon page o-f output needed by inventory control 
clerks^ This satis-fied the operational level o-f management 
in-formation needs. Upper and middle management do not 
recei v€? jjSuf -f i ci ent in-formation -from these systems to answer 
the '‘what should we be doing?" and "what is our status right 
now?" type questions. For NAVSUP, the need -for integrated 
information systems was made obvious during 1979 and 1980 
when naval units were^ required to operate in the Indian 
Ocean -for extended periods outside their normal logistics 
chain. Top management had di-fticulty in getting up to date 
information -from the ships, stock points, and ICPs to make 
the many decisions to adequately support all units. The 
lack o-f integration among the three major information 
systems has become a chief concern of the Inventory and 
I n f or mat i on Sy st ems Direct or ate ( SUP— 04 ) a t NAVSUP 
Head q u ar t er s . 

B„ INFURMATION SYSTEMS 

An information system, in general , consi sts of hardware, 
software, data, personnel , and procedures, EZach elem^ent 
mu. s t i n t er act c or r ec 1 1 y i n or d er t o h a '^'-e an ef f i c i en t and 
0 ?ffective system. With the remarkable advances in the-:* 
a m o L.‘ n t o f c c:. m p u. ter me m o r y a v a i. ]. a b 1 e , t h e p .1. v* o t a 1 e 1 e m e n t h a s 



shifted from the computer processor itsself to the data 
contained within a system. Data is now viewed as a valuable 
resource to be shared throughout the system. The use^r must 
become more responsible for the integrity of the data than 
was required by the older systems. This concept requires a 
coordinated effort by the designers, managers, and users to 
ensure gew information systems will satisfy the requirements 
of individual activities and allow access to and from other 
information systems. This need for integration has led to 
the development of a new methodolgy for systems design known 
as information engineering. 

Until recently, NAVSLIP activities at each level were 
allowed to develop information systems to satisfy their own 
requirements with little concern for interfacing with other 
systems. This “isolated'' design methodology evolved 
primarily because each activity's data processing 
requirements centered around specific functional programs 
such as payroll, personnel accoLtnting, or inv/entory 
management. Such programs were developed using second 
generation computers and were designed for independent file 
processing. During this period, the Navy implemented three 
large automated logistics systems to handle uniform data 
processing requi remen ts5 UICP (with UNIVAC hardware) tor 
the two inventory control points, UADPS-SP (with Burroughs 
equipment and file structures) for stoct: points, and BUADPS 



(with UNIVAC tfardware) for large fleet units. 
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compat 1 bi 1 i t y among these systems forced NAVSUP to support 
many redundant applications and data files. Because of the 
size of these computer systems, the immense investment in 
maintaining and expanding them through the years, and a long 
period of ADP funding shortfalls, the Navy was prohibited 
from replacing its outdated equipment and processes even 
though newer hardwares and more efficient applications 
ex i sted - 

C::„ NAVSUP NODERN I ZAT I ON PROGRAMS 
!. . Over vi ew 

NAVSUP is now involved with modernizing its three 
major information systems to catch up with the technological 
advances of the past twenty years and allow managers at 
every level to have access to the information they ne^ed. 

The programs are s UICP RESYSTEMI ZATIGN, UADPS Stock Point 
ADP Replacement (SPAF<> , and SUADPS Real-Time. The first two 
systems are being designed by FMSO in Meehan j. csburg , 
Pennsylvania using many of th^e techniques of information 
engineering, SUADPS Real-Time is under the cognizance 'jf 
!' -I a V y M a n a g e m e n t Systems S u p p o r ' i: 0 f f i r. e ( ju A V M S S 0 ) , N o r f o 1 I- ’ , 
Virginia. It is a much smaller system and has kept rriany of 
the traditional file design techniques.. Figure 2 summarizes 
the l-:ey elements of the three projects. 
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SUADPS Real -T i me 



SUADPS Real-Time le a user oriented on-line 
interactive supply and -financial system which utilizes the 
SNAP I computer hardware to support designated shipboard, 
Narine Air Group (NAG) Supply Departments, and certain Shore 
In termefji ate Naintenance Activities (SINA) mission support 
functions. It makes maximum use of the interactive 
capabilities of the hardware in data input, data update, and 
data base query operations. It replaces the original 
version of SUADPS which was a card oriented batch system 
designed for the UNI VAC 1500 system- 

The primary reason for the development of SUADPS 
Real-Time is to take advantage of the upgrade in computer 
processing capability made possible by the Shipboard Non 
Tactical ADP Program for large S5>hips (SNAP I)„ SNAP I 
r emo ved the sec on d g en er a t i on U 1 500 systems f r om the f i e 1 d 
activities and replaced them with a fourth generation mini 
computer, the Honeywell DPS-S. The DPS-6 increases thc9 
memory capabilty from 16,000 to 2,000,000 bytes and provides 
for on-1 me storage of at 1 east 12, 000 j, 000 bytes. Wi th thi s 
quantum leap in computer capacity, the capability for- 
creating a more effective system became a reality, SUADPS 
Real-Time is one of several on-line sys^-tems bt-jinq 
implemented on the SNAP I systems. According to its charter 
[Ref. 2], it is designed to n 



a. Reduce the time and e-ftort required to process 
supply transactions and to access supply 
i n-f ormat ion. 

b» Improve supply response times tor organ! r at i onal and 
i n ter med i ate 1 evel mat er i al r equi rement s - 

Ca Improve utilization of fleet operations and 
mai ntenance funds. 

d- Igiprove accuracy, consistency, and timeliness of 
supply, financial, and logistics data. 

e. Provide? a direct interface with maintenance systems. 

An important element missing from this design 
criteria is the need to interface with UADPS-SP or UICP, 
NAVhASSO chose to continue many of the file design 
techniques of the old SUADPS system to allow easier 
transition to the new system and interface with the ship’s 
3ld maintenance reporting system. This has resulted in data 
redundancy and lack of file integration- Many processes are 
duplicated for one transaction. Using a data base 
management system <DBhS) would have reduced the redundacy 
and possibly allowed better interaction with external 
systems. Keeping the imbedded file structures has also made 
the future development of a NAVSUP corporate data base much 
more difficult. Other factors such as getting a system out 
to the fleet as soon as possible to use the new hardware 
took pr ecedence . 

NAVMASBO’s implementation plan involves phasing in 
V e r s i c:i n s o f t h e n e »'*i S U A D PS R T as t h e y a r e d e v e loped a n d 
b a c k f i. 1 1 i n g p r‘ e v i o s 1 y i n s t a 1 1 e d s y s t e rn s . U n f o r t ix n a. t €-:* .1 y , 



users are discovering many bugs in the system. This 
decreases their faith in the system and increases their 
reluctance to change from many outdated processing methods 
such as using punched card input. Currently, Dixon 

<AS-37) homported in San Diego has the latest version of 
SUADFS Real ““Time on the west coast. Due to the phase-in 
approach;, stock control personnel are forced to perform dual 
processing until final system development is completed in 
approx i matel y two yec^rs. The dual processing involves 
entering data into the “real time“ files for query 
processing and requi si t i oni ng material, then downloading 
that data for processing to the “official'* data files for 
processing by the old SUADFS system running in emulation 
mode. While the old system is running, the ship loses its 
“real time" capabi 1 i 1 1 es. Addi ti onal 1 y , requisitions v^hich 
must be passed off-ship are being prepared and submitted in 
three different methods which vary from ship to ship 
depending on their experience. Requisition processing is 
accomplished by <1) direct input into a E^urroughs terminal 
and utilizing a fleet on-line program, (2) submitting a 
SUADFS tape to the stock point for UADFS processing, or <3> 
writing out a requisition document and having the stocf: 
point prepare the automated requisition card. 

SUADFS? Real-Time has created a new element in the 
shipboard supply department operations by giving remote 
access to its supply files. Under the old SUADFS 
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processing, one or two storekeepers and the stock control 
Officer were SUADPS trained. They were responsible for 
ensur i ng that supply documents were correctly prepared for 
submission to the data processing division. After the 
inventory programs were executed, they then had to wor^:; 
error listings of improper transact i ons- It was not 
uncommon for a single transaction to require two wee^.s of 
processing before being completed if it was originally 
submitted incorrectly. In the meantime, the rest of the 
supply department was working with printouts of the 
inventory files that were up to two weeks old. With S^UADPS 
Real-Time, all storekeepers will be involved with the 
inventory data. Remote terminals at stock control and most 
of the storerooms will allow direct on-line processing of 
receipts, issues, and requi si t i ons. This will require 
SUADPS? training for all supply personnel to ensure data 
1 nt egr i ty , 

The new system allows output of requisition files to 
either floppy disk, magnetic tape, or punched cards. 
Currently, the stock points are only capable of using t*ape 
or punched cards. Esecause of initial problems with the 
UADPS-SP system reading the Honeywell tapes, the majority of 
ships with SUADPS Real-Time are reluctant to change to the 
new technology and are continuing to use the punched card 
output that they used for twenty years. This severely slows 
p r o c e s s i n g t i me, T h i s </■« i 1 1 c: o n t i n u e t o b e a p r o b .1. e m u. n til 



the “second generation mentality" is removed through 
training and hope-Fully with the implementation of the SPAR 
equipment at the stock points which is being designed to 
allow direct transfer of requisitions by floppy disks. 

3. Stock Point ADR Replacement Project 

‘'The Stock Point ADP Replacement Project (SPAR) 
received its charter from NAVSUP in March 1983, It has two 
main objectives: (1) replace the computer systems at 25 
major data processing facilities that provide services to 72 
activities which utilize the Uniform Automated Data 
Processing System for Stock Points (UADPS-SP) ; (2) the 

moder ni z at i on of UADPSS-SP to improve the level of supply 
support provided to the operating forces of the Navy, 
Deployment of new hardware and software will extend into the 
1990'*s with a contract life of 24 years to allow for 
technol oqi cal improvements and capacity expansion as 
required- CRef. 3] 

Stock point computer systems have been operating at 
full capacity for years- Because of the sheer size of SPAR 
and the lead time for system acquisition and development, 
the Navy implemented the Navy Stock Point Logistic 
Integrated Communi ca.t i on Environment (SPLICE) as an interim 
program. The primary objectives of SPLICE are to relieve 
the saturation of computer systems currentlv at the stoctr 
points and to provide for the telecommunication needs of the 



moderni zed UADPS. 



SPLICE was envisioned as a quick stop-gap 



measure to allow for a controlled redesign effort in SPAR. 
However prob 1 ems with the establishment of network protocol 
for the Department of Defense Network (DDN) has delayed the 
actual implementation of SPLICE. Meanwhile, the design 
phase of SPAR has pushed forward. 

The SPAR project involves replacing 60 medium scale 
computers and converting or redesigning 7800 programs that 
contain 11.5 million lines of source code. It does not 
include the redesign or conversion of the hundreds of local 
programs that exist throughout the system. The completed 
system is being designed to efficiently interface with both 
the UICP and SUADPS Real Time systems- Since it is such a 
huge project, a “risk aversion" attitude has partitioned it 
into three main phasess (1) hardware acquisition with 
equipment selection now scheduled for March 1987, (2) 

conversion of the current UAr)pS system to execute on the new 
hardware, and (3) moderni z at i on of UAE^PS. Each phase has a 
separate manager at NAvSUP headquar ter s. 

The transistion plan for the r€?placement project 
discussed four different alternatives for replacing the 
current software including standard conversion, generic: 
COBOL, shell or bridges, and redesi«gn. An initial decision 
tc3 impO. ement SPAR with converted software vic:e a modernized 
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traditional methods. The cost of having the system fail 

during i mpl ementat i on at any stock point is deemed too high 

to risk,' Also, the feeling is that conversion will be the 

quickest method to get the new hardware to the activities. 

A final decision will be made in late 1985 after the 

redesign team at FnSD prepares its initial package, CRef 41 
¥ 

The SPAR redesign team at FMSO began its project by 
preparing a functional description of all the tasks 
performed by the current version of UADPS-SP, Utilizing a 
fourth generation software design tool, DATA DESIGNER, they 
compiled the logical relationship of all the functions and 
the data files with which they interact. This identified 
data, classes with one to one, one to many, and many to many 
rel at i onshi ps. The team took this output to the users and 

asked ‘'Is this really the way you do your processing?" At 
the same time^ they queried the users on what they thought 
the new system should do. This bottom-up design method 
contradicts one of the key elements of Informatiion 
Engineering (.IE), In IE, top management decides what the 
new system should do and lets the design wort:; top-down -in 
the conceptual stage. However, IE also assumes that 
corporate headquarters has a firm description of its 
information needs included in its strategic plan. The 
pressures of time forced FNSO to query the users first, mak 
managerial »^ 0 commendat i ons , and foi"ward its inte.ntions to 
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NAvSUP Headquar ter s = 



From the preliminary results, the FMSG team has 
decided to proceed with a phased i mpl ement at i on of the 
redesigned software and backfit orqani zat i ons with the new 
software as it is developed instead of attempting to 
prototype all of the changes on one system. This is 
si miliary to the SUADPS REAL-TIME implementation plan. The 
major difference is that under SPAR there will be no 
duplicate processing under emulation mode. Currently, the 
redesign team is continuing its development work while 
serving as a beta test site for a new fourth generation 
software design program. 

4. UICP RESYSTEMIZATIQN 

FMSO has also been tasked with designing the 
modernized software for the inventory control point (ICP) 
level. UICP RESYSTEMIZATION or RESDLICITATION is the ICP 
version of SF'AR. Uniform Inventory Control Point (UICP) is 
a collection of programs very similar to the UADPS-SP 
system. The current system involves lE^M hardware at two 
sites, SPCC in Mechani csbur g , Pennsylvania and ASO in 
Phi 1 adel phi a, Pennsyl vani a. RESYSTEMIZATION ef f orts began 
in 1978 with an e^-cpected completion date of March The 

project has already selected and installed IBM 3030/3090 
hardware. 

1 e s o f t w a r e r" e d e s i g n e f f o r t b e g a n b e f o r e t e 
d e v e 1 o p m e n t o f 1 e d e se- i g n t e c h n i q u e s o f I n f o r m a 1 1 o n 






Engineering. However, the redesign team has been in close 
communication with the SPAR team and would like to integrate 
jTiany of the concepts of IE into their project. This may 
prove to be very difficult due to the mechanics involved. 
Currently, the project is also geared towards a phased 
i mpl emept at i on with the financial accounting subsystem being 
the first scheduled to come on line. The system is built 
around the IBM IDMS data base system which could be a 
problem for integration of UADPS-SP AND UICP data. The 
interface between SPAR and UICP is deemed critical to the 
future development of a corporate data base capability. 
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III. SOFTWARE DEVELOPMENT/ INFORMATION ENGINEERING 



A. BACKGROUND 

To the layman, the quantum leap in computer technology 
during the past five to seven years has been, at best, mind 
boggling. Much attention has been given to the development 
and i mprovements in hardware? which have been easy to 
obser've. Early ccMiiputers that contained small amounts oi 
memory were physically huge and required a large investment 
of capital. Today, processors which work with almost a 
million bytes of memory are comnnonpl ace on workers" desks in 
almost every office building. Even as they have become 
smaller, computers are cheaper^ faster, more reliable, and 
easier to maintain than earlier models. 

Unseen to most people, a remarkable change in the manner 
in which computers are programmed has been talcing place, 

D i.‘ ring t h e e a. r 1 y d a y s o f comp u. t e r p i- ■ «::• g r a \ n m ;i. n g , t h e 

d e V e 1 C' p m e n t o f so f t w a was s e n*' e r e 1 1 i. m i ted b y t h e 

capabilities of the computer. As the computer became less 
I " e s t 1 c: ■(: i v e , t hi e p r" o g r a s b e c: a ro e m o r €■? c o m p 1 e b e c a la s e m a n 

demanded more from t h i s e 1 e c t r o n i c ^ ■ e s o u r c e . H o w e v e i-’ , l ( n 1 1 1 

recently, the manner in which people approached the 
pr ogr ammi ng pr ob 1 em r emai ned t he ssame = Uost s=-o f t ware was 
d e V el Dp e d t o p — c.1 o ui n a n ci was a p p 1 i c a t i o n o r f- u . n c t i o n o i e n 1: e d = 
S u t a Si c.1 e m a n d f o r s o I ix t. i o r"» s t o iT! o r e q e ‘ e ax 1 p r o b 1 e rr* s 



increased, the methodology of programming has slowly evolved 
into an "information engineering" project- To appreciate 
the power and compleMity of information engineering, a brief 
description of the earlier methods is needed- 

B, ERAS OF SOFTWARE DEVELOPMENT 

The evolution of computer systems and software 
development has been character i zed by three eras L"Ref, 5 
In the first era, programming was initially accomplished by 
hardwiring the computer. Each different application being 
executed on the computer required a complete rewiring of the 
computer. The programmers were, in fact, electrical 
engineers. Once the second generation computers were 
developed, non— enqi neer s became involved. The use of 
compilers and higher level programming languages gave 
programmers much more flexibility. But s-or a period of 
twenty-five ye^rs, all programs were developed to sol'-e a. 
specific problem. Much redundancy in the programming effort 
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algorithms and most programs had very limited di str i but! on = 
The second era reflected a significant leap in the 
capabilities and functions of computer systems. Systems 
i^ere noi^j being used by more than one pe-^rson or organization 
so programs had to be more flexible, F'roduct sof twa‘’‘‘e 
e •/ o 1 V e d w h i c h r " e q u i r e d m o n t h o r •/ e a. r ■ s- ‘ f d e s i q n i r “g , c* c j i n , 



testing, and evaluating be-fore being used. Libraries o-f 
common programs became necessary. However most software 
development still was application oriented, and the 
applications were becoming more and more complex. The cost 
of software development and maintenance began to skyrocket, 
and soon exceeded hardware costs. During this “growth** 
stage of data processing development, a better method of 
programming had to be found to control the escalating costs. 
Data processing experts^ such as C.F. Gibson and Richard 
Nolan voiced their concern over the uncontrol 1 abl e growth in 
data processing requirements and fried to provide industry 
with guidelines towards a “ mature “ DP environment CRef. 6 H. 
Nany of their concerns became real as computer processing 
moved into the third era. 

The third era of software development began with the 
arrival of mi croprocessor s and distributed computing systems 
and continues today. The need fo<~ software greatly ^exceeds 
the personnel and technical resources available. The fact 
t h a t m a n y f u. n c t i o n s a r e now h a r d w i r e d i n t o t hi e p ■ o c e s s o r s 
h e 1 p s , b u. t t hi ee c o m p* u t i n q w o r 1 d c a n n o 1 o n q e ■ a f f o r d t h e 
luxury of putting months or years into developing a program 
U ^ a t does not s a t i s v c u r r e n t: r e q u. i r e m e n t s . M a n v b u s i r** e s s e s 
a r" e d i s c o v e r i. n g ho w i m p n r t a n t t hi e c o rri p u. ter c: a ri b e t o b o t h 
t !i 0 i r d a 'y' -• t o - d i-n y o p e r a t i on s a n d t o t h e i r }. o n g r a ri q e p 1 a n n i n q 
e f f o t s « H o 0 V e r , m a n y u. s e r s a r e f r s t r a t e d w 1 1 h t h e 
t f ■■ a d i. t ;i. D n a. 1 p r o q r a i i i m i n g r e q ix i r e m e n t s and 1 1 mi i t a t i o n s . 



Charles Rubin states "Ideally, what’s needed is software 
with a flexible command processor that would let the user 
define • - . the way the user likes to communicate , . « The 

solution is beyond our current means, although there are 
some integrated packages on the horizon that promise 
•modeless" operation , . , , llRef* 7.1 This "need" requires 

a new method of programming- A major step in satisfying 
that requirement is the emergence of software engineering. 

C . SOFTWARE ENG I NEER I NG 

Previous programming techniques centered on a. flowchart 
approach that was concerned with procc^dural or "how to" 
questions- Software engineering is geared towards a "what 
to do" question and is functionally oriented- To ensure 
efficiency and ef f ect i veness of the software product, a 
great deal of planning is reqtiired- Hence, the engineering 
attitude is employed- It is a methodology that uses 
techni ques that ar‘e appl i cat i on i ndependent , 1 1 i s model ed 

on the time-pro'yen techniques, methods, and controls 
associated with hardware development and is centered on 
three key object! vess (1) a well defined miethodol oqy that 
addresses a software life cycle of plannin‘g, development, 
and maintenance, <2) an established set of software 
c o m p o n G n t s t h a t cJ o c: u m e rj t s each s t e p i. n t h e 1 i f e c: y c: I e a n d 
s h o w s t r a c e a b 1 1 i t y f r o m is t e p t o s t e p , a n d ( 7 a s e t o f 



predictable milestones that can be reviewed at regular 
intervals throughout the software life cyc:le« CRef. S.1 

The three phases of a software life cycle are the key- 
el ements of software engineering. The planning phase 
includes software planning, software requi r emen t s analysis 
and definition, and a re-view of the software r equi r en-«ent s 
specification. From the spec i f i ca t i ons generated during th 
planning phase, deliverables are created during the 
development phase. This phase includes two software design 
steps, coding^ unit testing, inLegration testing, and 
validation t casting. The “final phase is the maintenance 
phase which involves mai n t ai n:i. nq code or modifying the 
software to ensure its rel i abi 1 i t'v, effectiveness, and 
1 “ 0 ]. e V a n c e , T o d a y , 4 0 % t o 7 0 7, o f a c o mi p a r« s p r o g r a mi m i. n g 
effort IS invol-^-ed with software miai ntenance, lIRef 9 .I The 
large amiount of miai ntenance during the life cycle of the 
s o f t w a r e i s o f i: e n o v e r 1 o o k e d d u r i n g t h e p 1 ri n i n g p ki a s e a n d 
resources art9 not available when needeed, 

S o f t w a r e e n q i n e e r i n q i s d e f .i. n i e 1 y j. m n r o v i i -i g t h e 
e f f e c t i V e n ess and r e 1. i a b i 1 1 1 -y o f in a n y p r o q r a m m i n g p r o j e c t s , 
But it is still a traditional programiminq methodology i'n th 
sense that large teams of programimers are required as well 
as considerable timie. This does not solve the problem of 
t o d a -y ’ s u s e r s w h o i*"* e q u i r e t h e c a p a b i 1 i t t o i. n s t a n t a n g o u s 1 v 
a r-i s w e r s core g o f q u. e 1 1 o n r e g a r" d i ri g a w i d e r a n q e o f d a t a , 

! hey cannot afford to wait for a pr ogr amimi nq tearn to provid 



them with a software tool. Information engineering 
represents a radical change in program design that will in 
effect take the responsibility for the majority of 
programming away from the application programmer and place 
it in the hands of the user. 

D . I NFORMAT I ON ENG I NEER I NG 

Information Engineering <IE) is a discipline that is 
broader than software engineering and encompasses all the 
interrelated disciplines necessary to manage an effective 
data center. It ties the design of the data center squarely 
into the corporate planning processes of each organ i z at i on . 

A mature organization lives and dies on its data. Contrary 
to software engineering which focuses on the logic used in 
computerized processes, information engineering is primarily 
concerned with how data is created, updated, and used. 
Earlier programming methodologies were designed around 
static procedures. IE maintains a basic prt^mise that the 
type of data used in an enterprise do not change 
si gni f 1 cant 1 y while procedures using the data will. 

1 . Bui 1 di ng Bloc ks 

There are nine basic building blocks defined for 
information engineering as outlined in Figure 3. Each block 
IS dependent on the firm development of its predecessors. 



They ares 



a. Strategic requirements analysis 

b. Information analysis 

c. Data modeling 

d. Procedure formation 

e. Data use analysis 

f. Distribution analysis 

g. Physical data base design 

h. Program speci f i cat i on synthesis 

i„ Application generation without programmc^rs 

The strategic: requirements analysis block is the most 
important and the most c:«ver looked portion of IE- In this 
block, the overall objecrti ves of the enterprise and the 
information needed to accomplish those objectives are 
determined- Many organi zat i ons have learned the hard way 
about the wastefulness of appl i cat i on - software created to 
generate paperwork and give the managers little, if any, 
benefit- Onct? or qani z at i onal objectives have been 
determined, the second block performs a top-down analysis of 
the types of cJata that must be kept and how they relate to 
one anc'ther- This is a critical process be?cause the 
cornerstone of information engineering is that data 
structures will remain stable- E>urinq the third step, data 
modeling, a detailed logical data base design is created - 
The key is that the data is structured independent of how it 
will be used. The fourth block, procedure formation, 
concerns the events that change or use the data base- These 
procedures can and should be designed and pr ogr ammed by the 
u. s e r s - r o b n a b 1 e no n - p r o g r a m m i n q p e r o n n e 1 t a c c o m p 1 i s h 
t h !. s , 1 n f o (*■■ m a t :i. o n e n i. n e e i- “ i n g i s s t c* n g 1 y cj e e n d e r» t u p« o n 

f o i..t r 1 1 'f c:} e n e r t i o n r o q r a m fTi i n c:j 1 a 1 1 g u. a c^ e s w h i c h a r e b a s i c a I 1 y 



non-procedural and allow coding in Engl ishl ike statements. 
Additionally;, there is the capability tor automatic code 
generation using the procedure charts created during this 
bloc k . 

The fifth and sixth blocks, data use ana.lysi£ 5 > and 
distribution analysis, prepare the data orga.ni zati on for the 
physical' data base design step of block seven. In earlier 
methodologies, the physical structure of the data was 
dictated by the application being programmed. Block eight, 
program speci f i cati on synthesis, integrates the different 
procedures, documents any data changes, and creates 
functionally cohesive program code. Finally, block nine 
represents the capability of application development without 
programmers in the sense of dedicated programmers working as 
a team. In this block non-pr ocedur al 1 anguages allow the 
user to answer queries on the data base, model “what if" 
questions, streamline reports, and generally q€-?t to the data 
they need. Non-procedur al languages differ from procedural 
languages in the sense that a procedural language specifies 
how something is accomplished. A non-procedural language? 
specifies what is accomplished but not how in detail. 
Application developmt?nt without programmers is probabl / the 
most important and exciting element of IE. The vast backlog 
in application development in most organ! cat i ons has 
severely restricted the flow of i nf orm»at i on . 
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By using all oi the above blocks, corporations can 
develop flexible systems which meet overall or qani z at i onal 
information needs much more rapidly than by using 
traditional design methods and at an overal 1 1 ower «::ost» 

CRef- 10} 

2 n Life Cycle Stages 

^Software engineering assumes a life cycle of three 
distinct phases: planning, development, and maintenance- 

information engineering decomposes the life cycle into eight 
stages: (1) Business strategy planning, (2) Information 

strategy planning, (3) Ebusiness area analysis, (4) Ebusiness 
system design, <3) Technical design, ‘-6) Const ruct i on , (7) 

Transition, (&) F-'roduct i on - Each of these stages has a 

building block that addresses its main functions- A key 
element is the existence of a. data dictionary or 
enc'- cl opedi a that is referenced during each one of the life 
cycle stages. Without a rjood data dictionary, information 



engi neer i ng woul d be i rnpossi bl e. 
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3 - Steps in Intormetion Engineering CPef. 103 
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There are basically tour classes of data 
environments. Early programming methods involved oniv the 
tirsi: class: tiles- The second class, application data 

bases, include data bases designed tor separate 
applications- The third and fourth classes, subject data 
bases and information systems, require an enormous amount of 
sharing of data attributes and if uncontrolled can become 
unmanageabl e- The purpose of a data dictionary is to 
control that data- James Martin defines a data dictionary 
as “ a tool which lists all fields that are used, their' 
definitions, how and where they ar"e used, and who is 
responsible for them- All fields in all locations are in 
the data dictionary , " lIRef, 11.1 The data admi n i str ator 
needs the data dictionary to enforce agreement on the 
definition of each field in order to ensure compati bi 1 i t y of 
t h e d a t a t h r ou g h ou t the c or p or a t :i on - 

4 User Invol cement 

►-'* o 1 1") 0 r *7i a . j o r d i f f e r' e n c e be t w e e n t r' a c j i 1 1 o r • a 1 
s o f t ware d e e 1 c» p m e n t t e c h n i q u. e s and 3. n f o r' rn a t i o r? e r« q i n e e r' i n n 
is the degree of user i nvol -'eoien t In the past, the user 
tilled out a form s- 1 a t i n g h i s a p p 1 i c a t i o n i " e q ‘ ..i i r e m e n t a n d 
s o m e 1 1 me — on the a v e r a g e o f t h r e e o f o u r y e a r s .!. a. t e r — a 
p i e c e o f o l‘ t p u. t m i g li t s h o w u p ,, B o. t i n 1 n ?■ o r m a. t i o n 
engineering, the user is directly in'-oiveo in each of the 






stages- For instance, in strategic requirements planning, 
senior management must be involved to ensure the correct 
objectives and direction of the or gani :: at i on for the future 
are properly communicated- In information analysis, the 
user is primarily responsible for the completeness and 
accuracy of the or gani z at i onal data base- Finally, in 
application development without programmers, the user 
creates and utilizes the applications he needs to get 
results- This method of user involvement leads to a more 
flexible environment in which changes can be made easily and 
qui ckl y , 

5» Six Stages of Growth in E>ata Processing 

A final di f f erent i at i on between the data-or i ented 
analysis of i nf or mat i on engineering and the 

procedure-or i ented analysis of software enginc^erinq can be 
shown by d i s c u. s s i n g the e f f e c: t s o f- the si x s 1: a e s o f g r o w t h 
in data processing identified by Richard Nolan and shown in 
Figure 4 CRef« 123- During the first two stages, initiation 
and contagion, the data processing department is concerned 
with automating functional cost reduction applications of 
specific areas such as accounting or inventory control - If 
all goes well, additional requirements are considered,.. 

During the third stage, control , the DP department finds 
itself unable to keep pace with requi re‘ments- Often i:his is 
c a u s e d b y t li e lac !•:: o f a n o •/ e t'" a 1 1 p J. a n t h r o * j q h a li t t: h e 
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corporation for utilizing data proceseing. 
control phase, management upgrades documentation and 
reguires formalized just i f i cat i on for future appl ications- 
Integration i ss the fourth phase and is marked by a 
fundamental change in the way applications arce developed* 
Data is consol i dat ed * In the fifth stage, data 
admi ni strat i on , the organization has a wel 1 -devel oped data 
base* In the final stage, m^^.turitv, the data processing 
function “mirrors'* the way the organization operates and all 
is right in the world- 

Grgani zat 1 ons in stage 1 or 2 can successfully 
utilize procedure-~or i ented analysis and design techniques. 

A more mature organization must use the dat a-or i ented 
techniques because procedure-or i en t ed techniques make it 
virtually impossible to identify data redundancy which 
e>i i st s throughout the organi z at i on * 
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The traditional methods of software development are 
still important to smaller applications and to organi 2 at i ons 
just beginning to utilize data processing. Information 
engineering was not created to replace those methods* The 
primary goal of information engineering is to give larger 
organi z^t i ons the capability to design data p'rocessing 
systems that support the organi z at i on s objectives and 
capitalize on the value of the data resource* Corporations 
such as EMMon and government agencies such as the Naval 
Supply Systems Command have endorsed the concept of 
information engineering and are cur^‘e^tiy involved in 
projects based on its methodol oqi es. The “mature" 
organization of the future is? closer to becoming a realityc 



IV- 



data administration and vertical integration 



A. nvyERVIEW 

The design of fTfOdern i nt or mat i on systems is far more 
^.romplex than any project most organi zat i ons have previously 
attempted. As an organization moves through Nolan’s stages 
of ADR evolution, it is more di-f + icult to change its ADR 
structure to tit its information needs. No simple tools 
exist to assist corporate managers in planning the 
transition to the next phase. Techniques such as life cycle 
planning, stages of growth. Ebusiness Systems Rlanning and 
critical success factors all lack some integral elements and 
are not totally effective in today's highly technical, 
complex information world CRef- 133. Information 
Engineering is the latest attempt at successful planning of 
1 nf ormat i on needs. 

An organization cannot rely solely on the concepts of 
Information Engineering in creating information systems. IE 
s h o L\ 1 d b e V 3. e w e d as t h n u. c 1 e u . s o f a v a r i e t y o f d a t a. 
processing tools or techniques that when thoughtfully ' 
integrated furnish the organization with an effective system 
that handles information needs now a.nd will allow sufficient 
expansion to meet all future requi rement s . The following 
a Y" e o m e o f t tf e m a n y c o m p o n e n t s o f a c: o m p 1 e t e i n f o r m a t i o n 
y s t. e m as shown i n F i g u re S 3 
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Figure 5 - Components of Information Engineering 
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1. In-formation Centers 

2. Fourth Generation Languages 

3. Expert Systems 

4. Computer Graphics 

5. Programming Languages 
Database Management Systems 

7. Data Di c:t i onar i es 

3, Data Admi ni strat i on 

Most o-f these components are software tools that aid the 
system developers or allow easier retrieval of data by the 
ijserSa The last component. Data Admi ni strat i on , is a 
collection of management functions that when properly 
performed significantly ease the effort required in an 
Inf ormat i on Engi neer i ng project . 

B . DATA ADM I N I STRAT I ON FUNCT I DNS 

Data Admi ni str at 1 on is best described as the 
responsi bi 1 i t V for planning, coordi nat i nq , and managing an 
organi zati on" s data. E^asic functions to support that 
responsi b i 1 i t y have evol ved f r om admi n i str at i ve and 
technical issues involved with data base admi n i st r at i on . 
The concept of Data Admi ni str at i on is less than ten years 
ol d and i s f ar f rom bei ng a def i ned en t i tv . Most 
definitions of Data Admi ni str at i on embrace at least five 
areas; strategic data planning, data j-nodeling, data 
conventions and standards, data interchange and tools 
management. An overal 1 goal should be the est abl i shment o 
policies and guidelines for the management of data as a 
V a 1 u a b 1 e c: o r p o r a t © r s o u r c e . T' 1 1 e f o 1 1 o win g 1 i. ia t o f cJ u t i e ^5- 



oi a data admi ni str ator is r epr esent at i ve o-f those -found on 



position descriptions tor a variety o-f companies- 



I'lanaqes the devel opj-Bent o-f standards, methods, and 
guidelines -for data planning, analysis, data modeling, 
document at i on , and logical database design. 

Manages the coordination between users, project 
management, analysts, and management. 

Manages the logical database designs and the use o-f 
logical design so-ftware. 

Manages the establishment o-f the Data Dictionary and 
develops standards -for its use. 

Plans and manages the education o-f the sta-f-f on data 
planning, analysis, modeling, document at i on , and 
logical design. 

Manages the sta-f-f in providing data modeling support 
to all project ream system development e-f -forts. 

Pi-ovides logical database designs and performance 
specifications to database admi n i str at i on and verifies 
any required database design changes tor the project 
and user management. 

Provides an awareness of contemporary methods of data 
modeling and evaluates their application in the 
current organi zat i onal sett i ng . 

Manages the security and privacy of the data in all 
logical design. 

Manages the maintenance of the strategic plan. 

Provides the resolution of all data definition and 
usage issues. 

Originally, data admi n i str at i on was thought of as a 
purely technical function having primarv responsibility over 
the effectiveness and efficiencv of data bases and database 
management systems iE^BMS) CRef. 14,1. However, corpor at i ons 
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soon found that merely appointing someone to be in charge of 
data bases left a void in the overall management of data* 

The data admi ni str ator definitely needs to possess two types 
of talents admi ni strat i ve and technical* 

Admi ni strat i ve skill is required to handle management 
and policy affairs, to interact with various groups of 
concerned and affected people, and to define what should be 
in the or gan i at i on ' s data bases. The technical skills are 
required to determine implementation issues relevant to the 
specific data bases and to define how the organization data 
bases will be structured and accessed. 

The functions of data admi ni str at i on (DA) are often 
combined with those of database admi ni str at i on (DBA) in 
organi zat i ons where the same person performs both sets of 
functions. Many organi z at i ons consider the DA to be simply 
the chief DBA* For those organi zat i ons moving towards the 
maturi ty phase, combining Data Admi n i str at i on and database 
admi n i st r at i on f unc t i ons i s not r ea 1 i st i c * Those 
organi zati ons require the DA to have eMtensive knowledge of 
the organization and its overall composition. For instance, 
in Information Engineering, the Data Admi ni str ator would be 
fully involved in the first three steps? strategic 
requi rements pi anni ng , i nf ormati on anal ysi s, and data 
rn o d e 1 i n g * T h e r e a r e f e w d a t. a h a s e a d m i n i s t r a t o r s 1 a t 
p o s s e >:=• s the n e c e s s a y~ y s k i 1 1 s I: o {::« r o p e y‘ J. v e e c i.* t e t h o s e 
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functions as well as have the time to adequately control the 
data bases. 

The combination of these skills or rather the lack of 
combination often determines the placement of the data 
admi ni strati on function within the organi z at i on " s structure. 
When a data admi ni strati on shop is just beginning it is 
often placed lower in the orqani zat i onal heirarchy because 
upper management is unsure of the technical aspects of its 
data bases. However, to ensure better data consistency 
throughout the organization, it is better to separate the 
functions of the data admi ni strator from the database 
admi ni str at or and place the DA function high enough in the 
organi z at i onal chain to be effective in policy matters that 
affect information systems. 

C. DATA ADM I T4 1 STRATI ON VS. DATABASE ADM I NI STRAT I ON 

Figure 6 shows a comparison of data admi ni str at i on and 
database admi ni str at i on concerns [Ref. The basic 

difference involves interfacing with a particular data base 
vice structuring data independent of a data base.. Data 
admi ni str at 1 on must be concerned with the long term deesign 
needs and utilizes the data dictionary as a primary tool. 

The data admi ni strator has the overall responsibility for 
the organizat i on" s data resources, and is responsible for 
non technical activities such as planning and defining the 
c o n c e p t L« a. 1 f a m e w o r k f o r the o v e i"" a. 1 1 d a. t a b a s e e !i v- 1 r o n m e t , 
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not just that specifically limited to DBMS usage. 



Database 



administration is concerned with the efficiency of the 
actual database structure and DE^MS. The DE-iA is the 
organi 2 at i on " s leading technical expert on database related 
activities and is reponsible for the day-to-day operation of 
all database related activities. He is involved with the 
daily decisions and activitie?E^ which have immediate impact 
upon the organi 2 at i on s oper at i c«nal data bases. The DBA is 
not overly concerned with data modularity, ex tendabi 1 1 t y , or 
utility. Data modularity is the ability ot a data structure 
to accommodate more easri 1 y changes to the information 
requi r€?ments of the organi zat 1 on . Data ex tendabi 1 i ty is the 
ability of th& data structure to accommodate additions or 
deletions to instances of data without affecting the design 
of the structure or the programs that use the data. Data 
Li til], t y i s the a b j. l i t y o f a c.1 a t a s t r u c t u re to ee a 1 1 s f y t h e 
information needs of a variety of end users. 
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DATA ADMINISTRATION AT NAVSUP 



In November 1984, NAVSUP reorganized the Inventory and 
Information Systems Directorate <SUP-04) in a move to help 
gain control over current and future systems development- 
major point prompting the r eor gani z at i on was the fact that 
NAVSUP was supporting development of separate information 
systems without any integration between those systems- As 
part of the reorganization of SUP-04, a data admi ni str at i on 
branch was created <SUP-0414) as part of the Information 
Systems Management and ADP Security Division- Its primary 
objective is to develop a corporate data plan and logical 
data model for NAVSUP that will maximize sharing, minimize 
redundacy and coordinate all data flow within the Naval 
Supply System and its interfaces with external systems- 

The majority of the Data Admi ni strat i on E^ranch’s effort 
to date has been with defining goals and implementing the D 
function at NAVSUP. The branch has created the following 
objectives and a timjetable for the next two years: 

Mar 86 IMPLEMENT THE DATA ADMI N I STRAT I (3N FUNCTION 

Staffing POM and Recruitment 
NAVSUP Corpor ate Requi rement s 
Mi ssi on ESt at ement 
Policy and Procedures EStatement 



June 86 DEFINE AN OVERALL INFORMATION SYSTEM 
ARCHITECTURE TO SUPPORT NAVSUP BUSINESS 
FUNCTIONS 

Define Current Initiatives 
Create NAVSUP Steering Committee 
Develop NAVSUP Ebusiness Model 
Devel op Inf or mat i on Archi tecture 

Dec 86 DEVELOP DATA ARCHITECTURE TO SUPPORT THE 
NAVSUP INFORMATION SYSTEMS ARCHITECTURE 

Design NAVSUP Logical Data Model 
Develop Corporate Data Dictionary 

Jun 37 DEVELOP A NAVSUP TECHNICAL PLAN 
ENCOMPASS I NG TELECOMMUN I CAT I ONS , OFF I CE 
AUTOMATION, AND OTHER EXISTING NAVSUP 
INITIATIVES 



Document Systems Hardware and Software 
Develop Systems Concept Paper 
Perform Input Analysis 
Develop Technical Plan 

The above objectives support goals of (1) devc^loping the 
overall objectives of the data admi ni str at i on function and 
secure their endorsement by top management; (2) determining 
NAVSUP’’ s DA scope, in terms of both subject matter, and 
organ! zati onal components and programs; (3) assi qni ng 
overal 1 author! ty and responsibi 1 i tv; and (4) prcMiiul qat i ng 
overall or gan i z at i onal policy^ According to i l:s inission 
statement;, the data admi ni str at i on branch is dedicated to 
providing a systematic plan for developing standards and 
policies which ensure ultimate vertical and horiiuontal 
integration of data among the various NAVSUP and eMterna.l 
i nf or mat i on syst ems , 



Although the branch has been poorly sta-f-fed since its 
inception, a considerable amount of headway has been made 
towards achieving its -first year goals. An initial decision 
has been made tor SUP-0414 to be the proponent -for all 
NAVSUP i nt orrnat i on rc^sources and to develop the DA plan 
while FMSO is being tasked to accomplish the DA tasks. The 
•following is a list of SUP-0414 and FhSG functions as 
currently defined: 



SUP-0414 FUNCTIONS 

1. Develop and maintain a NAOSUP Corporate Data Plan 
and Logical Data Model to reflect the data 
structures required to support the information 
requirements of the Naval Supply System. 

2. Initiate and develop, in coordination with the 
Planning and Policy Branch, NAVSUP standards and 
procedures related to data resource management, 
including, but not limited to. Data Dictionairy 
Spec i f i cat 1 on Standards and Data Element Naming 
Convent i ons. 

3. Serve as NAVSUP arbiter to review and resolve data 
resource issues within ADP program development. 

4. Review Data Communi cat i on Requests to insure 
compliance with Data Adm:i ni st r at i on Standards and 
Pr ocedur es, 

5 „ .De ve 1 op and i mp 1 emen t E)at a E 1 emen t Nam i ng 

Standards and Policies for all NAVSUP ADP systems. 

6. Develop policy and procedures for data transfer 
across all NAv'SUP networks, including data 
downl oad to mi crocomputers. 

7. Manage development, i mpl ementat i on , and 

ma i n t en an c e of the Cor p or ate Da t a D i c t i on ar y . 

0. Act as NAVSUP I i ason with all e>;ternal data 

systems within Navy , DOD , and c i vi 1 i an agenc i es 
a n «d data s t a n d a t- ■ d i c a t i c* n e f -f o r t s . 
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9. Review System Life Cycle Maintenance Document at i on 
•for adherence to Data Admi ni st r at i on Policies and 
Procedures. 

10- Develop policy and standards for luqical data b 
design for all NAVSUP system development projec: 
Conduct post i mpl ement at i on reviews to insure 
compliance to standards- 

11- Develop NAVSUP policy and standards for 
initiatives that access any data basei, both 
Corporate and private- 



FMSO h unctions 



1. Perform system planninq- 

2. Provide access procedures and monitoring for all 
dat abases. 

3- Perform data and impact analysis- 

4. Assist NAVSUP DA Branch in determining 

Headquar ter " s Corporate data requi rement s - 

5- Provide input to policy- 

6- Implement corporate data model - 

7. Determine and maintain a record of relationships 
among da t abases , 

3- Develop corporate data dictionary- 

9- Monitor qualits/ and integrity of data- 

10- Function as technical DA expert - 

11- Establish document at i on standards for database 
systems. 

12. Conduct formal DA traininq- 

13- Evaluate various automated tools for DA 
devel opment , 

14- Serve as principle consultant on database design 
pro j ec t s and aud i t t r a i 1 s - 
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From the above lists, it can readily be seen that SUP-0414 
has a good idea o-f what it wants to accomplish but must rely 
heavily on FMSO to do so- What remains to be seen is how 
much top management support SUP-0414 will be given. The 
next step for NAVSUP's Data Admi ni strat i on Branch is to 
develop the NAVSUP DA Directive to outline all 

vv 

responsibilities and establish its corporate policy. 

E„ data administration and vertical integration 

One of the goals formulated by NAVSUP in its strategic 
plan is to ‘’Develop databases which support the single 
update of related data and provide the required views of 

that data to all levels of the work force" [Ref 16] » To 

achieve that goal requires the integration of NAVSUP'’ s 
information systems both vertically and hor i zontal 1 y . In 
relation to the three information systems discussed, SUADPS 
R E A L — T I M E , U A D F' 5 — 3 F’ a n c j U I C F’ , v e r t i c a 1 i n t e g r a 1 1 o n i r» o 1 v e s 
transferring information from one system to another, ie«. 
from ship to stock point. Horizontal integration involves 

passing i f o r m a t i o n from o r g c?. n i z a 1 1 o n t o o y" g a n a. z a t i o n o n t li e 

same level, ie.« from stock point to stock point. 

Integration of information systems require^s compatible 
hardware and software and wei 1 -devel oped data bases, NAVSUF* 
has a d d r e s s e d t hi e p r o b 1 e «t» o f h a r d w a y" e a n d s o f t v - j a r e 
c: o nr* p a 1 1 b i 1 i t •/ a ri d i n c 1 u. d e d t h o s e j- - e q u. i. r e m b r* t s in t h e 
s p e c i. f i cat i o n s f a r t !"« e S F’ A R s y stem a c q u. i s 1 1 i o n , I n d e e d , t hi e 



technology to allow communi cat i on between the three systems 
exists today. Additionally, at the completion o-f the SPLICE 
project, the capability -for UADPB-SP systems to communicate 
through the DEiN will be achieved. However, compatible 
systems cannot overcome weaknesses in data organ i s at i on . 

How valuable is having integrated information systems if the 
needed data does not exist, or no one knows whether the data 
is available or not, or if conflicting data exists, or if 
effective controls over the use of the data are lacking? 

The above weaknesses exist in most organi zations" 
information systems and are the primary focus of data 
admi ni str at i on « 

NAVSUP headquarters has a definite problem with 
integrating its three information systems because its 
overall ADP environment has never existed in s^tages 4 and '5 
of Nolan's cycles Integration and Data Admi ni sstr at i on « 

These two stages are c:har ac ter i zed by the integration of 
applications vice information systems and by the development 
and management of data bases. All of NAVSUP' s previous 
systems utilized file structures based on appl ications. 
3UADPS REAL-TIME has retained its redundant file structures, 
UICP RESYSTEMI ZATION is being designed around its current 
appl 1 cat 1 ons. The redesign of UADF*S-SF- is NAVSUP' s first 
attempt at using modern database structures and database 
m a n a g e rn e n t s y s t e m s as w ell as i" e s 1 1-' u. c t u r i n g a p 1 i c a t i o n s » 
NAVSUP is therefore ha'ving to move through two phases to 



catch up to today’s technology- This is primarily due to 
the requirement Tor NAVSUP to keep its original systems 
throughout the period that comparable orqani cat i ons were 
implementing data base systems- Another negative -factor is 
the decentr al i zed environment in which the NAVSUP systems 
have evolved. For two decades, the coordination of the 
three systems at the ship, stock point, and .TCP level was a 
low priority at headquar ter s- 

In an effort to support the goal of integrated 
information systems, NAVSUP' s strategic plan requires the 
establ ishment of a formal SPAR./ICP RESOLICTATIGN/SUADPS 
application working group to identify and justify 
integration opportunities. Although it initially restricts 
the concept of integration to the three current systems and 
their current appl i cat i ons, it is a beginning. For this 
integration team to be effective, it should be relatively 
independent of the management hierarchy in order to avoid 
the power struggles of each of the current systems and to 
escape-? the risk aversion attitude of corporate headquar ter s , 
The accessi bi 1 1 ty of data creates a multitude of questions 
regarding NAVSUP' s traditional support structure. The 
business of providing supply support to t.he ope.rating units 
o f t: h e i'J a v y r e a i n s the same. Howe v e r , N A V S U F’ s h o u 1 c:l t a k e 
a d V a n t age o f t e c h n o 1 o g i c a 1 a d v a n c e s , ]. o o \ ■ : a t t h e l\ r r" e n t 

a. u t G m a t e d -■* p p 1 i c a t i o n ?? a n ci i.t n c t i cj r? s a n d a s k I'-j h e t: h e v~ i t c a n 
1;? e ci o n e b e 1 1 e r 1 1. h r) e w t e c h n c:* 1 o g y , F o r .i. !" * s t a n c e , i f a. s h? 1 p 



has access to the worldwide inventory of parts, does it need 
to submit a reterrral to the closest stock point if it is 
not carried there? Why not refer the requisition to the 
stock point or activity that has the part available and 
avoid the additional referral to the ICP? In a segregated 
information or gani z at i on , the answer would be because that 
function does not exist at the shipboard level. It is the 
ICP"s responsi bi 1 i ty . Finding the optimum solution to 
questions created by the new availability of data will be 
difficult at best. It requires a total rethinking of the 
processes. 

Many of the questions that the integration team will 
address should have been answered prior to the beginning of 
the UICP RESYSTEMIZATIOW project or at least the Information 
Engineering portion of the SPAR project. An example is the 
interfaces needed between the three current systems. That 
guidance should have on ginatc^d from headquarters as part of 
a top-down planning technique of the strategic requirements 
phase. The redesign team at FMSO usced a bottom-up approach 
to define the probable interfaces. No decision has been 
made about whether all the interfaces are correct and 
complete. In the meantime, F’MSO is beginning to feel the 
pressure of command dictated completion dates» 

The objectives of Data Adrni ni strat i on support the goal 
of integrated information systems. E»ata is the most 
important component of information systemsa The key is 



knowing what data exists and where it is located. The 
functions o-f the DA include developing and mai ntai ni ng a 
data dictionary which can answer queries regarding 
1 n f ormati on resources. For instance, it NAVSUP needed to 
know the data entities and applications containing standard 
MILSTFsIP requisition in-formation such as QUANT I TY-ON-ORDER , 

w 

the Data Admi ni strator should be able to respond with 
information detailing the fact that QUANT I TY-QN-ORDER is 
represented by si.v different variable names in 23 different 
programs and be able to list them. Data dictionary 
information is e.xtremely valua.ble in systems integration. 
Therefore, the integration team should study the overall 
Data Administration organization at NAVSUP to help 
understand the complexities of structuring data to 
facilitate system interfaces., NAVSUP may have begun its 
Data Admi ni strat i on program too late to play out its 
complete rolce in the information engineering project for 
3PAR« However, NAVSUP is not just in the business of supply 
support;; it is also involved in retail operations, 
petroleum, household goods shipments and many other 
i nf ormati on-dependent f unct i ons. The esta.bl i shment of 
effective integrated systems in one ar e a j M a v p* a v’ f the w a y 
f or add i t i onal i mpr 0 '»’emen t s in ot her i nf or mat i on s-yst ems . 
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PROBLEMS WITH DATA ADMINISTRATION AT NAVSUP 



The establishment ot the data admi ni strati on function at 
NAVSUP is now at a crossroads. The definition of goals and 
objectives for DA are relatively complete. Implementation 
of those objectives and achieving the goals will not be as 
easy. Top management at headquarters must dedicate support 
and make a decision regarding the scope of the DA function 
to give the Data Admi ni strat i on Branch the power it needs to 
fulfill its responsibilities. SUP-0414 has encountered many 
of the same problems in establishing the data admi ni str at i on 
function as its count erpar t s in other large corpor at i ons. 
Among those are lack of expertise and resistance to change. 
Other problems such as the budget constraints for the E^A 
evolution are unique to a military or government 



environment. The following is a list of factors that are 
currently hindering the proper development and effect! ven 
of the data admi ni strat i on function at NAVSUPs 



1, Incomplete staffing of DA E^ranch; The current 
plan allocates three positions in 3UP-0414. Only 
one position remained filled for the past 10 
months and it is now vacant. Recruitment does not 
seem to be a. top priority, 

2. Limited ADP background of staffs The one staff 
member previously employed devoted the majority of 
her time getting up to speed on ADP terminology 
and database techniques. This has resulted in a 
lack of credibility with the principal players at 
FMSO and the information systems sponsors at 
NAVSUP, 



3 . The DA E'-r anch '' s 1 ocat i on i n NAVSUP " S 

o !“ g a n i z a 1 1 o n a 1 ?? t r u c t u r e i ^ ? t o o I o w 1: o v.; o 1 i c 1 1 



cooperation -from i nf oriTiat i on systems sponsors: 
SUP~0414 is competing against the firmly 
entrenched support structures of the three current 
information systems. DA objectives which require 
a rethinking of application functions are 
unachievable in the current structure without 
power struggl es. 

4„ Attempting to establish a DA environment in a 
decentr al i zed ADR environment: NAVSUP 

headquarters has no control over the data or the 
applications development of its information 
systems- Data is processed around the world while 
the design and development of the three 
information systems is accomplished by two 
separate activities. Implementing data standards 
will be more difficult than if NAVSUP functioned 
under a centralized ADP concept. 

5. Attempting to implement DA functions in time to 
determine data needs for SUADPS REAL-TIME/ SPAR/ 
UICP interface: If data admi ni str at i on is to 

effectively support the information engineering 
concept, data needs and interfaces must be 
determined prior to system design. SUP-0414 is 
way behind the power curve regarding the current 
development of information systems. The needs of 
the three projects may be dictating the DA efforts 
instead of the true needs of the corporation- 

ib- Corporate inexperience with database management; 
Data admi ni str at 1 on functions evolved from 
database admi ni str at i on « It is difficult to 
determine long range and overall data needs 
without experience with designing and operating 
speci f i c databases. 

7:, Data Admi ni strat i on conflicts with the traditional 
organ! z at i onal philosophy of NAVSUP: Headquarters 

is Lincomf or t abl e with the concept of DA because it 
is historically a reactive or risk aversion 
centered organ i z at i on . The lack of ADP oriented 
personnel at headquarters restricts the knowledge 
of information engineering and the value of 
wel 1 -i ntegr ated data. 

3- Current time schedule for achieving DA functions 
waits too long before tangible benefits are 
a c h i e v' e c j ; An c* r g a n i. z a t i o n s li c: h a s N A V S U F' n e e d s t o 
see tangible benefits in order to justify the 
expense of the DA function. In the government. 
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this is especially a problem due to the budget 
process and current deficit spending concerns. 

The above problems are by no means fatal to the data 
admi ni strat i on function- However, collectively they 
critically restrict the evolution of the DA function at 
NAVSUF\ If NAVSUP is serious about providing integrated 
data throughout its or gani z at i on , then it must dedicate top 
management resources to solve these problems. BUP-0414 has 
identified the needed tasks. However, no real authority 
exists to ensure they are performed. 
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CONCLUSIONS 



V‘ . 

The world of information systems design has undergone a 
remar kabi e change since NAVSUP first implemented SUADPS, 
UADPS-SP and UICP. Unlike many corporations which have 
implemented database systems, NAVSUP is not afforded the 
opportunity to make an easy transition from the application 
centered projects to the concept of information engineering 
and integrated systems. Data Admi ni str at i on is one 
management function that can allow NAVSUP to eventually 
catch up with its information needs if it is given enough 
support . 

The UADPS-"SP redesign effort will be the key to NAVSUP 
having integrated information systems, SUADPS REAL-TINE and 
UICP have already been committed to appl i cat i on-dependent 
file structures, UADPS-3P will be the prime interface 
vehicle for the integration of data. The FNSG UADPS-iSP 
Redesign Team has taken the lead in performing the strategic 
requirements function of i nf ormt?.t i on engineering. It must 
be completed prior to the design of the logical databas=-e 
structure, NAVSUP should respond as soon as possible to 
their queries regarding the desired functional activities of 
UADPS-SP. 

Aside from providing token input regarding naming 
standards, the NAVSUP Data Admi ni strat i on Branch has been 
:i. I e f f e c: t i v e in a s s i s 1 3. ri g the infer in a 1 1 o n e n g i n e e r :i. n g 
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project. Its obvious weakness has been in sta-F-Pinq, Now 
that the goals and objectives -for data admi ni strat i on have 
been delineated, NAVSUP should decide what it is going to do 
with its orga.ni zati on . DA cannot evolve effectively as it 
is currently located and manned. If a true IE effort is 
envisioned, it should be moved up the NAVSUP organization to 
either the SUP-OOX or SUP-04 level to give it the full 
“top-down" support it requires. Otherwise it should be 
moved to FNSO where the knowledge of database management and 
design resides and where it can realize its objectives 
relating to integrated data design. Thenj^ after tangible 
benefits become evident, cons^i derat i on can be given to 
expanding the scope of DA and migrating it to headquarters 
for higher level admi ni strat i ve purposes. 

The UADPS-SP redesign project is not a true, top-down 
information engineering project. Ne'-'erthel ess, many of the 
issues the FNSO team is addressing art? top management 
issues. This results in the t?qui valent of a “middle out" 
approach to IE which makes the development of a cor por at e 
data dictionary exceedingly difficult. The NAVAL SECURITY 
GROUP for example required six months just to standardize 
400 names for a corporate dictionary. UADPS-SP is much more 
involved. With the current time restrictions placed on the 
redesign effort, serious consi der at i on should be given to 
d e V eloping a d i c t i o n a r y w h i c h i s m u. c h s m a 1 1 e r i n s cope a n d 
which facilitates the transition to a data-or i ented 



UADFS-SP. If this is successful, then a concept known as 
selective retrofitting can be used to incorporate new 
applications as they arise and evolve towards a 
comprehensive, integrated corporate dictionary. 

Today, there is a critical need to integrate information 
systems within NAVSUP. Information needs throughout the 

I' 

organization have increased trernendousl y « The capability to 
have an integrated system exissts, if NAVSUP can gain control 
of the data- SUADPS Real-Time, SPAR, and UICP 
RESYSTEMI ZATION began at different times and are in 
different stages of development.- For NAVSUP to properly 
integrate those systeems to allow worldwide access to data at 
all three levels of the logistic chain, it will have to free 
data design from appl i cat i ons- An effective data, 
admi ni str at i on organization is needed to ensure the data 
requirements of the overal 1 corporation are satisfied- 
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